wilf’s 


Wilf Hey ?déoks at the 
effects of random 
numbers on zombies and 
drunkards, and suggests a 
little light reading. 


fi m™ 


hese days, computer room 
" security usually means 
passwords, encrypted files, virus- 

hunting software and combination locks. 
Many years ago the company I worked 
for decided to install security measures — 
a lock on the sliding door to the several 
computer labs, and new telephones that 
cut off at midnight (don’t ask me why). 

The new lock on the door of my lab 
was faulty; it had become jammed when 
the guard, checking before signing off, 
left the room after warning me I was 
alone. At about two in the morning I 
packed up to leave, and found I couldn’t 
—nor could I telephone for help. Worse 
still it was the Saturday morning of an 
American four-day weekend, so I didn’t 
know when help would arrive. 

I launched my 20-stone frame at the 
sliding door, thinking I could knock it 


off its rail after a few attempts. On the 


very first attempt, the door tore off its 
rail, popped out of its frame, traversed 
the width of the corridor and destroyed 
an office partition. I picked myself up, 
surrounded with bits of broken door and 
shattered partition, to see the whole wall 
across the corridor, where I had come 
from — 150 feet long, with six computer 
rooms off it — moan, buckle and fall, 
shooting nails inches into the air. I was 
free, but at what price? 

I was innocent, and so didn’t suffer 
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any disciplinary action, but from then on 
I carried a reputation. This was an 
international company, so I found my 
fame preceded me to Japan, Belgium 
and elsewhere — I would rather have 
been noted for my programming skill. I 
can’t really kid myself that my superb 
coding technique warranted their calling 
me ‘a real heavyweight’. 


ZOMBIES AND MONSTERS 

There are several areas where 
programmers find random numbers 
useful, but the two that seem to be most 
commonly used are in games and 
modelling. In fact the sort of games that 
use random numbers are usually models 
themselves. A ‘model’ in this sense is a 
computer program that simulates real- 


It’s fascinating to create a simple model program and then modify parameters to study 
the effect. It is especially easy to build models in GW-BASIC, debug and tune them, 
and then convert the parameter assignments into INPUT commands. A simple 
example is as follows; a model of an inebriated fellow’s homeward journey — you can 
specify the percentage likelihood of his staggering on any one step, and then watch 
until he falls into the ditch on either side, or until you interrupt with a keystroke. Note 
that it could be quite a long time before he falls into the ditch, even if he staggers with 
each step. Of course, if you set the chance to zero, he will go home in a sober, rather 
uninteresting straight line, and the program will have to be interrupted. 


life events, such as flight, queues in a 
bank, casino gambling, or perhaps 
roaming around an enchanted cave, 
dodging dragons. 

Much has been written about 
(seemingly) random numbers and how to 
generate them, and most high-level 
languages have a command or two that 
make them fairly easy to create. 
However, there are still some questions 
concerning how to use random numbers 
for modelling. 

One quite simple technique is the 
‘Zombie Wall’ (or sometimes “Zombie 
Door’). This enables random data for 
your program to take on an extra 
dimension — the randomness of time. 

Imagine that there is a large wall, 
with a narrow door-shaped opening in it. 
Then think of thousands of zombies 
lumbering towards that wall. Most will 
smash their face against the bricks, but 
every so often one will walk through the 
opening and reach the other side. 

You can incorporate a Zombie Wall 
into a program by generating a lot of 
random numbers — each number being 
like one of the countless zombies. The 
opening in the wall is another test you 
put in the program — one that will stop 
the vast majority of zombies short. 
Consider this piece of BASIC: 


100 RANDOMIZE TIMER 


110 FOR I = 1 TO 10 
120 J=0 
130 J=J7+1 


140 K = INT(RND*100) 
150 IF K > 9 THEN 130 
160 PRINT J 

170 NEXT I 


Line 140 gets a random value between 
zero and 99 for K, but the program never 
uses that value directly. Line 150 is the 
wall — it stops all the zombies (random 
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values of K) that lie between ten and 99. 
However, even then the program won’t 
use the surviving zombie. Instead it uses 
a simple counter — J is a count of the 
zombies since the previous surviving 
one. Note that J is reset (line 120) every 
time a zombie manages to find the 
opening, getting past line 150. 

The result of this program is that ten 
numbers will be printed out (one at a 
time, at line 160) — you can of course 
change how many you get by modifying 
line 110. These ten numbers are not just 
random integers, they are random 
intervals between things happening. If 
you gather a large amount of these 
numbers and make a graph of them, you 
will find that smaller numbers appear 
more commonly — although you could 
continue for a fairly long time before a 
zombie actually goes through an 
opening, and therefore get quite a large 
value for J — but this will only happen 
very occasionally. 

If you have participated in any of the 
various role-playing games, whether 
fantasy or science-fiction, you may have 
seen the gamesmaster rolling dice 
repeatedly while you carried out some 
move and then apparently continue as if 
he had done nothing. Quite possibly he 
was using a Zombie Wall method — if he 
had thrown a total below four, he would 
have interrupted your move to announce 
that some calamity had overcome you — 
a monster or a meteor storm perhaps. 

You can use the same technique 
within a computerised dungeon — with a 
bit of code resembling the above (the 
code for the calamity would replay line 
160). The normal progress of the game 
would appear between lines 120 and 130 


ete ee 


SELF-MADE PROGRAMS 


This month’s SuperDisk contains two of the most interesting submissions for our self- 
replicating program contest. Pat Middleton (Leigh on Sea, Essex) sent a program written in C, 
using a very long-winded but effective technique. George Rebello (London) wrote an A86 
program with an algorithm for label generation, rather than with an internal copy of everything. 

Robert Treen (West Acton, London) sent a Turbo Pascal version, quite elegant yet with 
extremely wide source lines. As in most versions, the method used involved a program with 
two almost identical halves - one half active, the other dormant, serving as data to be copied. 
The active half copies the dormant half out as a file twice over, with slight modifications, to 
produce an output identical to the program’s own source. Incidentally, this same trick of self- 
generation is used by the DNA molecules in all terrestrial life. 

Another winner is Steve Thomas, whose A86 source consists of one enormous DB 
statement, over 1,400 bytes long (that’s the assembler equivalent of Basic’s DATA statement). 
This assembles into a 368-byte program called WILF.COM, which when executed puts a friendly 
message on the screen: 


Hello Wilf, 

This program will generate its own source code. 

Re-run this program diverting the output to a file (eg. >wilf.8) 
Then compile it using the A86 assembler. 

From: 


Steve Thomas 
(followed by his address) 


Bill (Madbill) Gunn of Dunfermline recalled a one-line PDP (mainframe) program that would 
propagate itself into successively higher memory locations, but initially questioned (as so 
many of you did) whether it would be possible to write a source-replicating program on the PC. 
He included an outline of his progress toward the goal, even though three computer studies 
graduates of his acquaintance declared it impossible. 

Having achieved the goal, he set to the task of minimising the length of the source. Using 
Zortech C, he eventually created his best effort - 269 bytes of perfection he calls GENESIS.C 
(when run, its output, created by redirection, is called PHIL.C of course - C standing for 
Collins). It’s listed here, broken into eight lines, though it should really be one long line. 


char H[11]={109,97,105,110,40,41,123,99,40, 34,0}, 
T[6]={34,41,32,59,125,0};c(M) char*M; 
{printf (M) ;print£(H) ;printf(M) ;printf£(T) ;} 


\ 


— perhaps by putting a GOSUB as line 
125. The total number of turns allowed 
would be coded in line 110, and the 
frequency of the calamity adjusted by 


Wesley (0734 794000), priced £36.94 
(including VAT). As you can guess from 
the VAT charge, this 700-page book 
includes disks. 


into MS-DOS, this extremely impressive 
book includes clear discussions and 
examples. However, it does require (for 


modifying the number in line 150 — the 
smaller the number, the rarer the 
calamity will be. 

Let’s hear of original 
implementations of this idea, either in a 
computer game or model — any language 
will do. One suggestion: a program to 
run a passenger lift, aware of calls from 
all floors of a tower block. The program 
may presume that passengers want to go 
up from the ground floor, but down from 
the other floors. The Zombie Wall comes 
in when you exercise the program — 
sending random passengers for the call 
button on each floor. Note that the lift 
must not stop (unless requested from 
inside) until it gets to the ground floor if 
it is full. 


LATE SUMMER READING 

Regular correspondent Mike Williams 
tells us of a favourite book he has come 
across; Undocumented DOS by Andrew 
Schulman and other, from Addison 
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the most part) a working knowledge of 


If you are of a mind to delve deeply interrupt programming. It is probably nv. 


OUT OF DATE 


Soon after | started this column, | got an impassioned letter from one programmer, begging 
me not to deal with dates. At the time, | tended to agree with him - too much is available about 
calculations with dates, and so on. However in recent weeks | have had a few letters 
complaining about the complexity of date functions in some languages, and the 
inconvenience of having an assembler subroutine to call the MS-DOS date routine. 

Well, just this once (unless you ask for more) | will present a simple routine to determine 
the day of the week for any date from 1st March 1900 to 31st December 1999. It can be written 
in virtually any language, so | put it here in GW-BASIC for all to see. In this | have stayed away 
from a DIM statement, although you might like to use one. This routine expects you to key ina 
date in the form 31,12,91 (commas separating day, month and year). No error-checking is 
performed, but you could add that if you wish. You escape from the routine by entering 0,0,0. 


100 INPUT DY,MO,YR 

110 IF DY=0 OR MO=0 OR YR=0 THEN 310 

120 IF MO > 2 THEN 150 

130 MO = MO + 12 

140 YR = YR- 1 

150 X = DY + INT(2.6*(MO+1)) + YR + YR\4 

160 ON (X - (X\7)*7 + 1) GOTO 170,190,210, 230,250,270, 290 
170 PRINT "Sunday" 

180 GOTO 100 

190 PRINT "Monday" 


main() {c(" 

char H[11]={109,97,105,110,40,41,123,99,40,34,0}, 
T[6]={34,41,32,59,125,0};c(M) char*M; 

{printf (M) ;printf£(H) ;print£(M) ;printf(T) ;} 

cas 


He also had the cheek to suggest an alternate Zortech C program that outputs its own source: 


main() 
{ 
printf ( "its own source\n" ) ; 


} 


There were many excellent entries to our little contest - and from them, some interesting ideas 
I'll share with you another time. Meanwhile well done to Pat, George, Robert, Steve and Madbill 
who will be receiving their well-deserved prizes soon. 


100 CLS 
110 INPUT "What chance of stumbling";CHANCE 
120 IF CHANCE < 0 OR CHANCE > 100 THEN 110 
130 DITCHS$=STRING$ (19,176) 
140 RANDOMIZE TIMER 
150 MAN = 40 

COUNT = 0 

2» COUNT = COUNT + 1 

180 STAGGER = INT(RND*100) 
190 IF STAGGER < CHANCE/2 THEN MAN = MAN - 1 
200 IF STAGGER > (100 - CHANCE/2) THEN MAN = MAN + 1 
210 PRINT DITCH$ SPACE$(MAN-20) CHR$(234) SPACE$(59-MAN) DITCH$ 
220 KS=INKEYS$ 


230 IF LEN(K$) > 0 THEN 270 

240 IF MAN > 20 AND MAN < 59 THEN 170 

250 PRINT "Fell into ditch after";COUNT; "steps." 

260 GOTO 280 

270 PRINT "Interrupted" 20 - ABS(MAN - 40) "steps from ditch." 
280 REM 


Experiment with other parameters as well - perhaps the occasional oil slick (generated by a 
Zombie Wall) that slips him three places to the left of right, instead of one; maybe a gradual 
bend in the road, or a narrow stretch? An automatic stumble over a sleeping policeman? An 
attractive pub on one side, to which he veers? 


going to be particularly useful to you 
unless you have a fair amount of 
knowledge about assembly language, C, 
or both. It includes a great diagnostic 
‘ool (called INTRSPY) which works like 


a periscope into MS-DOS. There’s also a 
useful hypertext help database, which 
includes all known MS-DOS interrupts — 
both documented and undocumented. 
Another recent discovery is an 


200 GOTO 100 

210 PRINT "Tuesday" 
220 GOTO 100 

230 PRINT "Wednesday" 
240 GOTO 100 

250 PRINT "Thursday" 
260 GOTO 100 

270 PRINT "Friday" 
280 GOTO 100 

290 PRINT "Saturday" 
300 GoTo 100 


310 REM 


The main trick is in line 150, where a special calculation determines what effect the month has 
_on the result. If you transfer it into another language, remember that integer division is being 


used at the end of that line — ignoring any remainder. The expression in the ON..GOTO 


. command in line 160 is the mod seven function of X - the integer remainder when X is divided 


by seven — plus one, to select the correct PRINT command. 
Leap years could be a problem, but they are catered for by a very simple trick (lines 120 to 


_ 140); January and February are counted as months 13 and 14 of the previous year. In this way, 
___ the leap day falls at the end of our artificial year, and so does not change the calculation one 
little bit. : 


Abacus book, which I can thoroughly 
recommend: Programming VGA 
Graphics by Jan Rueggeberg (contact 
Computer Manuals, 021-706 6000), 
priced £37.59 (including VAT). This 
book includes disks with lots of 
programs and tools. It helps you build up 
a library of tiny programs, treating them 
like MS-DOS external commands — so 
that you can program many VGA (Video 
Graphics Array) effects within BAT 
files, or from an execution shell in your 
programs. It is disappointingly short on 
technical points, but has oodles of source 
in Pascal, Basic, and C. Also, it wisely 
steers clear of assembler code. 

If you would like lighter reading, try 
the series of Programmer’s Phrase 
Books from Sigma Press (0625 531035), 
which have varying prices (around £6). I 
bought the one for C (there are also 
some for dBASE and other languages). 
These pocket-sized books are 
constructed along the same lines as 
language phrase books for tourists. 

This is a fairly clever and well- 
executed idea, with ample examples of 
things that you already know how to do 
in your favourite language, but don’t 
know how to do in C (or dBASE, or 
perhaps another language). While they 
are on the expensive side, they do prove 
to be very useful. 


TURBO C AND FAKING IT 

It appears as if a lot of assembler 
language programmers prefer Eric 
Isaacson’s A86 Macro Assembler (as I 
do). Those who use the power of high- 
level languages sometimes want to get 
down to the nitty gritty of assembler. 

My profound thanks must go to Doug 
Fisher (Workington, Cumbria), who 
attempted to use the A86 tool 
FAKE.EXE (which is meant to be 
substituted for MASM so that you can 
put AS6 statements into a Turbo C 
program) rather than be confined to 
MASM statements. 

He found that his version of Turbo C 
does not pass the ‘/MX’ switch to 
MASM (as both Turbo C and A86 
documentation state), but instead passes 
‘/ML’. Getting out the good old PC 
Tools, he patched TCC.EXE to do the 
job as it said it would. In relative sector 
340, hexadecimal displacement 0110, he 
found /ML and substituted /MX all 
perfectly successfully. @ 


Tips, arguments and 
ideas are gratefully 
received by: 


Wilf’s Programmer’s 
Workshop 

PC PLUS Magazine 
Beauford Court 

30 Monmouth Street 
BATH, BA1 2BW 
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